|
|
|
|
|
|
|
Figure 11.4.
The specification window for the
frmAccountMaintForm
form. |
|
|
|
|
|
|
|
|
The Graphical User Interface Subsystem Class Hierarchy Model |
|
|
|
|
|
|
|
|
Classes that control the interaction between forms and business/domain classes can be members of complex class hierarchies that show interface inheritance and delegation. You incorporate interface inheritance by assessing the various kinds of behavior that forms exhibit redundantly. For instance, if all your forms have Add, Modify, and Delete buttons that behave similarly, you could have an interface class, IInfoMaintenance, that provides a common interface for this type of behavior. The IInfoMaintenance class would have the following methods: |
|
|
|
|
|
|
|
|
Public Sub clickedAddBtn()
Public Sub clickedModifyBtn()
Public Sub clickedDeleteBtn() |
|
|
|
|
|
|
|
|
The IInfoMaintenance class would need to be declared globally for some subsystems, as follows: |
|
|
|
|
|
|
|
|
Global theIInfoMaintenance As New IInfoMaintenance |
|
|
|
|
|
|
|
|
For GUI subsystems implemented as ActiveX components, you would declare the interface object variable as MultiUse. MultiUse enables client applications to create objects from the class. That is, you can create many instances of this interface class. However, you need only one instance of such an interface class, so a public declaration is suitable. |
|
|
|
|
|
|
|
|
In some cases, an interface class for form controllers is not enough. You can have behavior for each Add, Modify, and Delete button that is common across many forms. Certainly, you wouldn't want to repeat the same code in each of these forms, although |
|
|
|
|
|
